Rethinking Success in Software Projects: Looking Beyond the Failure Factors

The notions of success and failure in software projects are confusing. Failure is often considered in the context of the iron triangle as the inability to meet time, cost, and performance constraints. While there is a consensus around the prevalence of project failure, new projects seem destined to repeat past mistakes. This chapter tries to advance the discussion by offering a new perspective for reasoning about the meaning of success and the different types of software project failures. In order to court project success, practitioners need to rise beyond a fixation with the internal parameters of efficiency, thus bringing forth the effectiveness required to secure project success. The chapter begins by discussing the limited insights from existing project failure surveys, before offering a four-level model addressing the essence of successful delivery and operation in software projects. Following consideration of outcomes and time, the chapter offers a series of vignettes and mini case studies that highlight the rich interplay between the four levels of success, before addressing the types of measures underpinning the four levels and the need to develop a multi-dimensional perspective to obtain a more accurate picture regarding the success of a project. 2.1 The Extent of Software Project Failures The popular computing literature is awash with stories of software development failures and their adverse impacts on individuals, organisations, and societal infrastructure. Indeed, contemporary software development practice is regularly D. Dalcher (*) NCPM, University of Hertfordshire, MacLaurin Building, 4 Bishops Square, Hatfield, Hertfordshire AL10, 9AB, UK e-mail: [email protected] G. Ruhe and C. Wohlin (eds.), Software Project Management in a Changing World, DOI 10.1007/978-3-642-55035-5_2, © Springer-Verlag Berlin Heidelberg 2014 27 characterised by runaway projects, late delivery, exceeded budgets, reduced functionality, and questionable quality that often translate into cancellations, reduced scope, and significant rework cycles (Dalcher 1994). The net result is an accumulation of waste typically measured in financial terms. For example, in 1995, failed U.S. projects cost $81 billion, with an additional $59 billion of overspend, totalling $140 billion (Standish 2004). Capers Jones contended that the average U.S. cancelled project was a year late, having consumed 200 % of its expected budget at the point of cancellation (1994). In 1996, failed projects alone totalled an estimated $100 billion (Luqi and Goguen 1997). In 1998, 28 % of projects failed, at a cost of $75 billion, while in 2000, 65,000 U.S. projects were reported to be failing (Standish 2000). McManus and Wood-Harper (2008) reported that the cost of software project failure across the European Union in 2004 was €142 billion. More recently, a McKinsey–Oxford survey of more than 5,400 software projects revealed that half of all projects significantly fail on budgetary assessment, while 17 % of projects actually threaten the very existence of the company, with the average project running 45 % over budget and 7 % behind schedule, while delivering 56 % less functionality than predicted (Bloch et al. 2013). According to the report, achieving $15 million in benefits now requires an average spending in excess of $59 million. Yet, software project failure is not a new phenomenon. The first indications of the problem and mention of the term ‘software crisis’ were made during the NATO conferences in 1968 and 1969 (Naur and Randell 1968; Buxton et al. 1969). Indeed, conference attendees reported a set of symptoms that would resonate with the issues raised by developers and managers today. Over 30 years ago, a GAO report in the USA (Anon 1979) showed that there were serious problems associated with the development of software. Less than 2 % of the total value of contracts could be used efficiently as delivered and a further 3 % could only be used after changes. The rest of the projects had the software delivered but never successfully used; the software paid for but not delivered; or the software used but extensively reworked or later abandoned. Moreover, the first edition of the best-selling book in software engineering tells the story of a huge IBM software project with major cost and schedule delays which teetered on the brink of disaster for a number of years from the perspective of the project manager trying to stabilize the project (Brooks 1975). Indeed, the OS360 project came close to bankrupting IBM. Consultancies and polling organisations have attempted to collect market data about the prevalence of failure. The Standish Group, for example, has been compiling an annual failure survey since 1994. In 1995, 31.1 % of U.S. software projects were cancelled, while 52.7 % were completed late, over budget (cost 189 % of their original budget), and lacked essential functionality (Standish 2000). Only 16.2 % of projects were completed on time and within budget; only 9 % were in larger companies, where completed projects had an average of 42 % of desired functionality (ibid.). The 1996 cancellation figure rose to 40 % (ibid.) before improving to around 15 % in 2002 (see Fig. 2.1). However, the most recent figures reveal that the current failure rate is 21 % (Standish 2011) with 63 % of overall projects labelled as not successful. Note that problems associated with cost 28 D. Dalcher